1. Field of the Invention
This invention relates in general to the field of instruction processing in computer systems, and more particularly to an apparatus and method in a CPU for executing application programs that consist of program instructions belonging to different instruction set architectures.
2. Description of the Related Art
A first-generation computer was only capable of executing programs that were encoded using a unique set of programming instructions. The unique set of programming instructions, or instruction set architecture (ISA) was to be used to develop application programs for execution only on that first-generation computer. Because of this constraint, system designers typically selected a particular computer for use as a system central processing unit (CPU) based upon its hardware characteristics (e.g., speed, power consumption, etc.) in conjunction with its instruction set's ability to implement certain critical functions within a system design. Once the CPU was selected, the system application programs were developed using instructions from the CPU's instruction set and the application programs were exclusively executed on the selected CPU. If system designers desired to upgrade the system's CPU to a more powerful processor, then they were required to recode the system application programs using instructions from the instruction set of the more powerful processor. In the early days of software engineering, this was not a significant encumbrance, primarily because there were not very many application programs in existence, and those that had been developed were not very complex.
Because a CPU can be easily programmed to perform a wide variety of functions within a system design, within just a few years the number of CPUs and application programs in the marketplace increased exponentially. In parallel with these events, technological advances in the integrated circuit design and fabrication arts began to release a steady stream of more powerful and complex CPU designs. And as these more powerful and complex CPU designs were exploited, a number of modification and upgrade mistakes were made as a result of recoding existing application programs. So, hardware and software designers were required to focus on preserving and reusing a substantial amount of code that had already been developed and tested for use with particular CPU designs. Consequently, as newer CPUs were introduced, in addition to implementing a whole “new” set of instructions, the CPUs retained the capability to execute applications that were coded with “old” instructions. Typically, this ability to execute multiple instruction sets was bounded by a particular manufacturer's line of products. For example, Digital Equipment Corporation produced a VAX11 CPU that supported newer VAX11 instructions and older PDP11 instructions.
Today, the number of application programs and their complexity continues to grow. In addition to this growth, another factor has provided both a motivation for innovation as well as a cause for concern. That is, the number and diversity of instructions sets that are available today for use in programming applications has resulted in designers often first choosing a specific instruction set for implementation of a system design. Following this selection, one of many CPUs is selected that implements the specific ISA. In fact, many present day processors implement more than one ISA. These processors are also capable of executing an application program consisting of program modules that are coded by instructions from different ISAs, i.e., a multiple-ISA application program. Accordingly, a system designer can specify a specific ISA for encoding a specific set of program functions (e.g., signal processing algorithms) and select other ISAs for encoding other types of program functions (e.g., operating system functions, I/O functions, general purpose functions).
Program instructions are represented as binary values. When a particular program instruction is fetched from memory and provided to a multiple-ISA CPU for execution, the CPU must have some way of knowing which set of instruction decoding rules to apply in order to correctly process a program instruction that has been fetched from a multiple-ISA application program.
One approach to indicating the ISA mode for program instructions is to encode the ISA mode as an additional field of the instruction. But this approach is very memory inefficient because additional memory bits are required for each instruction in a program. A more workable approach, employed by present day multi-ISA CPUs, recognizes the fact that adjacent program instructions in a multiple-ISA application program tend to be from the same ISA. Hence, the technique that is used today to indicate the ISA mode of particular instruction streams is to insert a special program instruction into the instruction stream that directs the CPU to switch ISA modes when instructions from a different ISA are programmed. For example, when a CPU is executing a program module consisting of ISA 1 instructions, and the module wishes to transfer program control to a subroutine comprised of ISA 3 instructions, prior to transferring control to the subroutine, an ISA 1 mode switch instruction must be executed that directs the CPU to switch to ISA 3 mode. Following this, program control is transferred to the subroutine that consists of ISA 3 instructions.
The technique described above comes in various forms. Hammond et al., in U.S. Pat. No. 5,638,525 and U.S. Pat. No. 5,774,686, discusses a “switch” instruction that directs a multi-ISA CPU to perform an ISA mode switch and to transfer program control. Jaggar, in U.S. Pat. No. 5,568,646 and U.S. Pat. No. 5,740,461, discusses the use of mode bits within an internal CPU register to signal a specific ISA mode. Under Jaggar's approach, a calling module first executes an instruction to set the mode bits in the internal CPU register to indicate the ISA mode of a module that is to be called. Following this, control is transferred to the called module. Nevill, in U.S. Pat. No. 5,758,115, and U.S. Pat. No. 6,021,265, describes the use of predetermined indicator bits within a program counter register for signaling ISA modes. The program counter register within a CPU carries both the address for the instruction that is to be fetched from memory and the predetermined bits indicating the ISA mode of the instruction.
All of the above techniques have one shortcoming in common: there is an interdependency that exists between components of a multi-ISA application program that extends beyond the simple transfer of program control. More specifically, a transferring component must know the particular ISA mode of a component to which flow is to be transferred in order to direct the CPU to switch ISA modes. One skilled in the art will appreciate that this is a difficult approach for use in a complex application program environment because each time a given component of a multiple-ISA application program is encoded into a different ISA mode, it forces a designer to modify all of the components that are referenced by the given component as well, thus increasing the chances for bugs to enter into a system design.
Years ago however, Larsen, in U.S. Pat. No. 5,115,500, proposed an approach for enabling a CPU to switch ISA modes during the execution of a multiple-ISA application program that did not require the insertion of a mode switch instruction into the flow of a transferring component. Larsen associated a program instruction's address in the CPU's address space with one of several ISA modes. In essence, Larsen used the upper bits of the program instruction's address to indicate its ISA mode. Hence, all instructions corresponding to a specific ISA mode were stored in one or more memory segments that corresponded to that specific ISA mode. Although Larsen's technique addressed the issue of inserting mode switch instructions into an application program, his technique for using the upper bits of a fetched instruction's address as an indication of the instruction's ISA mode is restrictive because it requires that the CPU's address space be partitioned into fixed and equal-sized segments. And fixed, equal-sized segments do not represent the distribution of components according to different ISA modes within a multiple-ISA application program. Larsen's technique for switching ISA modes is inflexible and memory inefficient.
Therefore, what is needed is an apparatus that enables a multiple-ISA CPU to select a particular ISA mode for processing a particular program instruction that does not employ fixed and inflexible segments within the CPU's address space.
In addition, what is needed is an ISA mode selection apparatus that provides for execution of a multiple-ISA application program, where a given component of the application program can be modified to a different ISA mode without requiring that all components referenced by the given component be modified as well.
Furthermore, what is needed is an apparatus for executing a multiple-ISA application program on a CPU that eliminates the need to insert special mode switch instructions into the flow of a first component of the application program in order for the first component to transfer program control to a second component that is encoded by instructions from a different ISA mode.
Moreover, what is needed is a method for executing multiple-ISA application programs that reduces the number of changes required to the application program when one of its subcomponents is modified to employ instructions from a different ISA.